Conversation
form_interface is now split between form_reader_interface and form_writer_interface for example.
been replaced by PersistenceReader and PersistenceWriter.
in persistence directory.
Removed a few files that were restored in the merge with main accidentally.
|
@phlexbot format |
|
Review the full CodeQL report for details. |
| } | ||
|
|
||
| m_pers = form::detail::experimental::createPersistenceReader(); | ||
| m_pers->configureOutputItems(output_config); |
There was a problem hiding this comment.
I think you're correct about this. Will review and probably change. Thanks.
There was a problem hiding this comment.
I think this needs a rename but can't be eliminated without rewriting more of PersistenceReader. We use m_output_items to figure out what file and technology to use when making a Token to get row ID.
|
|
||
| form_reader_interface::form_reader_interface(config::output_item_config const& output_config, | ||
| config::tech_setting_config const& tech_config) : | ||
| m_pers(nullptr) |
There was a problem hiding this comment.
How about output_item_config -> io_item_config? container_config? I think we're going to need it in both the reader and the writer.
There was a problem hiding this comment.
The location information on data to read should not depend on configuration.
There was a problem hiding this comment.
Other than the (global) input file-names, a reading job does not need to tell FORM where and what objects are stored, FORM should find them. Whereas on output, configuration does determine which outputs are written where.
| config::tech_setting_config const& tech_config) : | ||
| form_writer_interface::form_writer_interface(config::output_item_config const& output_config, | ||
| config::tech_setting_config const& tech_config) : | ||
| m_pers(nullptr) |
There was a problem hiding this comment.
Will investigate. I agree that it shouldn't change. Thank you for catching this.
| virtual void configureTechSettings( | ||
| form::experimental::config::tech_setting_config const& tech_config_settings) = 0; | ||
|
|
||
| virtual void configureOutputItems( |
There was a problem hiding this comment.
Agreed, I expect that I can remove everything dealing with output config from the reader-flavor components. I'll report back if it doesn't work for some reason.
| } | ||
| } | ||
|
|
||
| void ROOT_TBranch_Read_ContainerImp::setFile(std::shared_ptr<IStorage_File> file) |
There was a problem hiding this comment.
This one I think has some reasonable future applications. We might want to read multiple input files in the same job in the future like the old framework does. It might well be a no-op right now though.
Why do you think we should remove it?
There was a problem hiding this comment.
Once you have a container (on read), wouldn't it know its file?
| return; | ||
| } | ||
|
|
||
| void ROOT_TBranch_Read_ContainerImp::setParent(std::shared_ptr<IStorage_Read_Container> parent) |
There was a problem hiding this comment.
not sure whether we need this for read.
There was a problem hiding this comment.
Will investigate, thanks.
There was a problem hiding this comment.
Not sure that we would split associative... Do we need them on read and write?
|
@phlexbot format |
Format Fixes Applied✅ clang-format fixes pushed (commit c47a8c6) |
This PR splits
form_interfaceinto two components:form_reader_interfaceandform_writer_interface. This split saves FORM time by avoiding lock contention between read and write processes and prepares for RNTuple support that does not have members for anRNTupleWriterwhen only reading from a container.All of the layers that power the former
form_interfaceare split in this way. A handful of functions shared between reading and writing have been made free functions inform::experimental::detail.